Run a parallel pre-check before updating toolchains by FranciscoTGouveia · Pull Request #4752 · rust-lang/rustup

FranciscoTGouveia · 2026-03-15T20:40:33Z

Instead of sequentially checking each toolchain for updates, rustup update now first checks all toolchains concurrently and only then performs the updates (if needed).

This brings two advantages:

A no-op rustup update is now ~2x faster (see below);
After updating a toolchain, there is no need to wait for the remaining toolchains to be checked for updates; this is especially helpful in cases where only nightly needs updating.

Benchmarks were run using hyperfine (20 iterations on a 50 Mbps connection) on a setup with 11 toolchains, and no regressions were observed.
For the no-op rustup update, this patch was 2.2x faster; for cases where a single toolchain was updated, there was no measurable difference.

CC @epage

src/cli/common.rs

FranciscoTGouveia · 2026-03-15T20:42:30Z

src/cli/common.rs

+        future::join_all(channels.iter().map(|(_, d)| d.show_dist_version()))
+            .await
+            .into_iter()
+            .map(|v| v.map_or(true, |opt| opt.is_some()))
+            .collect()
+    };


Is there a cleaner way to achieve this?

Am I reading it right that now for every toolchain that needs to be updated, the update is checked twice?

Yes, I forgot to add a comment about this, sorry.

I see two possible ways to proceed:

Accept the cost of performing a double check. In practice, since the first check is done concurrently in a batch, the overhead should be relatively small.

Do a small refactor, starting in DistOptions::install_into(), to allow skipping the second check.

@FranciscoTGouveia I think we should try to avoid double checking if the changes involved are not super disruptive 🙏

I have been thinking about this, and my initial idea was to add a new manifest field (of type ManifestV2) to the DistOptions struct; however, I believe that would change the semantics quite a bit, since it would store more than just "options".

A direction I am more inclined toward is to reuse the manifest returned by show_dist_version(), which is currently discarded since we only call .is_some() on it.
Pairing this with a potential new install_with_manifest() method in InstallMethod (alongside the existing install()) would allow us to skip re-downloading the manifest.
What do you think?

A direction I am more inclined toward is to reuse the manifest returned by show_dist_version(), which is currently discarded since we only call .is_some() on it.
Pairing this with a potential new install_with_manifest() method in InstallMethod (alongside the existing install()) would allow us to skip re-downloading the manifest.
What do you think?

Sounds pretty good to me.

A direction I am more inclined toward is to reuse the manifest returned by show_dist_version(), which is currently discarded since we only call .is_some() on it. Pairing this with a potential new install_with_manifest() method in InstallMethod (alongside the existing install()) would allow us to skip re-downloading the manifest. What do you think?

@FranciscoTGouveia Yeah I agree with that. It'd be nice if the old installation method can be refactored to use the newly-introduced one by fetching the manifests before the call. I imagine there shouldn't be a lot of dependency issues in doing so?

src/cli/common.rs

djc · 2026-03-16T08:58:46Z

src/cli/common.rs

+        join_all(channels.iter().map(|(_, d)| d.show_dist_version()))
+            .await
+            .into_iter()
+            .map(|v| v.map_or(true, |opt| opt.is_some()))


I'm confused by this logic. show_dist_version() seems to merely yield the latest available version, but that a DistributableToolchain has a manifest with a rust component with a version is_some() doesn't mean that it's newer than the installed version?

Sorry, I do not think I fully understood your comment.
The rationale for using show_dist_version() comes from how it's used in rustup check.
As I understand it, show_dist_version() only returns Some when the hashes do not match (i.e., there is an update available), which aligns with what we need here.

In this setup, for toolchains that do not require updating, we would never reach .get_rust_version(), since .dl_v2_manifest() returned None.

Apologies if I've misunderstood or overlooked anything.

As I understand it, show_dist_version() only returns Some when the hashes do not match (i.e., there is an update available), which aligns with what we need here.

You're completely right. Might be good to add a docstring for show_dist_version() and maybe consider renaming it.

Sounds good, I will take care of it. :)

Apologies, could you clarify where you were suggesting putting updated_dist_manifest()?
I have renamed it to fetch_dist_manifest, which I believe is more accurate than the previous show_dist_version().

For reference, this is the updated code, where .is_some() has been replaced with .unwrap_or(None).

@FranciscoTGouveia Sorry for not being super clear. I was only referring to the renames. show_dist_manifest() may be replaced by updated_dist_manifest() since it will only return a value when there is actually an updated dist manifest, right?

For show_dist_version() I think it'd be better to just inline it as per #4752 (comment).

…ifests

src/dist/mod.rs

src/cli/common.rs

+        join_all(channels.iter().map(|(_, d)| d.show_dist_version()))
+            .await
+            .into_iter()
+            .map(|v| v.map_or(true, |opt| opt.is_some()))


djc · 2026-03-18T13:19:47Z

src/toolchain/distributable.rs

+            .await
+    }
+
+    pub async fn show_dist_version(&self) -> anyhow::Result<Option<String>> {


Since this has a single caller, maybe this should be inlined into its caller instead?

(If not, should do top-down order such that show_dist_version() comes before fetch_dist_manifest().)

djc · 2026-03-18T13:21:50Z

src/install.rs

+        self.install_with_manifest(None).await
+    }
+
+    pub(crate) async fn install_with_manifest(


Suggest just adding the argument to install() instead of adding a wrapper, since calling it with None is fairly trivial.

djc · 2026-03-18T13:24:28Z

src/dist/mod.rs

+    pub(crate) async fn install_into(
+        &self,
+        prefix: &InstallPrefix,
+        manifest: Option<(ManifestV2, String)>,


I think it's fairly unclear with all the places you're passing around (ManifestV2, String) (or (Manifest, String)) what the relation is between those or what the String contains. Perhaps it's worth wrapping these in struct type with named fields?

@djc It is worth noting that this is the return value of .dl_v2_manifest(). OTOH maybe it is worth it to extract that in a separate commit though.

djc · 2026-03-18T13:26:28Z

src/cli/common.rs

+        join_all(channels.iter().map(|(_, d)| d.fetch_dist_manifest()))
+            .await
+            .into_iter()
+            .map(|r| r.unwrap_or(None))
+            .collect();


So this is sort of just silencing/ignoring errors? Is that what we did before?

Instead of the type annotation, I would use turbofishing and leaving any inner types implied, as in collect::<Vec<_>>().

djc · 2026-03-18T13:28:42Z

src/dist/mod.rs

    targets: &[&str],
    fetched: &mut String,
    cfg: &Cfg<'_>,
+    prefetched_manifest: Option<(ManifestV2, String)>,


Does this actually need to take ownership ownership of the manifest, or could it make do with a reference?

FranciscoTGouveia requested review from djc and rami3l March 15, 2026 20:40

FranciscoTGouveia commented Mar 15, 2026

View reviewed changes

FranciscoTGouveia force-pushed the update-performance branch from 18df18c to d6cc274 Compare March 15, 2026 21:34

djc reviewed Mar 16, 2026

View reviewed changes

FranciscoTGouveia force-pushed the update-performance branch from d6cc274 to 5332ad0 Compare March 17, 2026 17:58

FranciscoTGouveia added 2 commits March 17, 2026 17:58

fix(toolchain): extract manifest fetching out of show_dist_version()

b10a7dd

feat(install): add install_with_manifest() to reuse pre-fetched man…

4a68765

…ifests

FranciscoTGouveia force-pushed the update-performance branch from 5332ad0 to 58defd5 Compare March 17, 2026 17:58

FranciscoTGouveia requested review from ChrisDenton and djc March 17, 2026 18:15

feat(toolchain): run a pre-check before updating all toolchains

3afbe36

FranciscoTGouveia force-pushed the update-performance branch from 58defd5 to 3afbe36 Compare March 17, 2026 20:09

rami3l approved these changes Mar 17, 2026

View reviewed changes

src/dist/mod.rs Show resolved Hide resolved

src/cli/common.rs Outdated

join_all(channels.iter().map(|(_, d)| d.show_dist_version()))

.await

.into_iter()

.map(|v| v.map_or(true, |opt| opt.is_some()))

This comment was marked as duplicate.

Sign in to view

FranciscoTGouveia marked this pull request as ready for review March 18, 2026 11:01

djc reviewed Mar 18, 2026

View reviewed changes

Conversation

FranciscoTGouveia commented Mar 15, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rami3l Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as duplicate.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rami3l Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This comment was marked as duplicate.

Uh oh!

djc Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rami3l Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rami3l Mar 15, 2026 •

edited

Loading

rami3l Mar 18, 2026 •

edited

Loading

djc Mar 18, 2026 •

edited

Loading

rami3l Mar 18, 2026 •

edited

Loading